unlock: Use deployment backing dir

Closes: https://github.com/ostreedev/ostree/issues/3391
Basically it's not uncommon to make `/var/tmp` a separate
partition, but this constrains the amount of data that
can be written to `/usr` when unlocking.

Change things here to write to the deployment's backing
dir which is part of the same rootfs as the storage
and is lifecycle bound to the deployment, ensuring
it gets GC'd.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3396 from cgwalters/release

Release 2025.2

Post-release version bump

Signed-off-by: Colin Walters <walters@verbum.org>

Release 2025.2

Signed-off-by: Colin Walters <walters@verbum.org>

tests/auto-prune: Don't go negative

- First I kept wondering what the magic of 10000 was here before
  looking above and noticing it matched the number of dtb files.
  Make a shared variable so the connection is more obvious
- Next, I *believe* the intention of this test was to test
  the edge case of bytes vs blocks, but we ended up subtracting
  blocks and I think recent FCOS images happened to get small
  enough that we started going negative here.
  Fix this to convert the bytes into blocks.

Merge pull request #3278 from ueno/wip/dueno/pkcs8

sign: Support generic "spki" type of commit signatures

sign: Support generic "spki" type of commit signatures

The current "ed25519" signing type assumes raw Ed25519 key format for
both public and private keys. This patch generalizes it by adding a
new signature type "spki" which uses the X.509 SubjectPublicKeyInfo
format for public keys. Keys in this format can easily be created with
openssl tools and provide crypto agility[1] as the format embeds
algorithm identifier.

The supposed use-case of this feature is to attach multiple signatures
with different algorithms to a single commit, so even if an algorithm
turned vulnerable, the signatures made with other algorithms can still
be used as a fallback. For instance, signer can create an Ed25519
signature along with a quantum-resistent ML-DSA signature.

The following are a couple of implementation notes:

- The private keys shall be stored in the PKCS#8 format, though future
  extensions may support other format such as opaque key handles on a
  hardware token.

- The "spki" signature type prefers the keys to be encoded in the PEM
  format on disk, while it still accepts base64 encoded keys when given
  through the command-line.

1. https://en.wikipedia.org/wiki/Cryptographic_agility

Signed-off-by: Daiki Ueno <dueno@redhat.com>

tests: Use tap_ok/tap_end in test-signed-commit.sh

Signed-off-by: Daiki Ueno <dueno@redhat.com>

sign: Add PEM reading facility

This adds a new class OstreePemReader, which reads PEM blocks from an
input stream.  This would be useful for the "x509" signing backend, as
the keys are typically stored in the PEM format.

Signed-off-by: Daiki Ueno <dueno@redhat.com>

sign: Factor out logic to read key blobs

This defines a new interface OstreeBlobReader, which encapsulates the
key file parsing logic. This would make it easy to support custom file
formats such as PEM.

Signed-off-by: Daiki Ueno <dueno@redhat.com>

sign: Use explicit_bzero to clear secret key material

Suggested in:
https://github.com/ostreedev/ostree/pull/3278#discussion_r1675696052

Signed-off-by: Daiki Ueno <dueno@redhat.com>

sign: Fix typo in error messages and comments

Signed-off-by: Daiki Ueno <dueno@redhat.com>

Merge pull request #3395 from cgwalters/syncfs-clarification

commit: Clarify that syncfs is of repo/tmp

commit: Clarify that syncfs is of repo/tmp

We saw this in an error message:
```
error: Generating commit from rootfs: syncfs: Not a directory
```

I'm pretty sure it's this function call but let's be a bit
more sure by adding a bit more context.

Merge pull request #3387 from smcv/debug3386

test-gpg-verify-result: Show what the result was before asserting about it

Merge pull request #3394 from vmorris/patch-1

Update introduction.md

Merge pull request #3393 from champtar/fsfreeze-boot

Use fsfreeze_thaw_cycle(/boot) instead of fsync(/boot)

Update introduction.md

slight rewording to remove redundancy

Use fsfreeze_thaw_cycle(/boot) instead of fsync(/boot)

Grub doesn't support replaying XFS journal, so when using
XFS for /boot, fsync() or syncfs() are not enough and can
leave the system in an unbootable state.

Signed-off-by: Etienne Champetier <e.champetier@ateme.com>

Merge pull request #3389 from jlebon/pr/drop-finalize-staged-path

boot: Drop ostree-finalize-staged.path

boot: Drop ostree-finalize-staged.path

This effectively reverts ac1a919f ("boot: Add
ostree-finalize-staged.path").

A bug came in on the OCP side that demonstrates that the way things are
setup right now is racy. If a reboot is triggered quickly after staging
a deployment, the whole pipeline of:

- ostree-finalize-staged.path, which triggers
- ostree-finalize-staged.service, which triggers
- ostree-finalize-staged-hold.service,

may not fully have happened before systemd isolates to `reboot.target`
which will want to kill all pending jobs.

Just directly starting the systemd unit is less elegant but much more
explicit and gets rid of any possible race because it's directly part of
the staging operation.

Fixes: https://issues.redhat.com/browse/OCPBUGS-51150

test-gpg-verify-result: Show what the result was before asserting about it

Helps: https://github.com/ostreedev/ostree/issues/3386
Signed-off-by: Simon McVittie <smcv@debian.org>

Merge pull request #3385 from cgwalters/log-xattr-conflict

core: Fix bare-user xattr canonicalization

core: canonicalize bare-user xattrs

Previously we were erroring out if xattrs were provided in
non-canonical (e.g. unsorted) form all the way down to just
the bare-user path. But for archive repos and dirmeta we
canonicalized.

Canonicalize bare-user xattrs on both read and write consistently
instead of erroring.

Signed-off-by: Colin Walters <walters@verbum.org>

tests/basic: Add lots of user. xattrs

This exercises our requirement for xattr sorting.

Signed-off-by: Colin Walters <walters@verbum.org>

commit: Add errprefix for bareuser metadata

To aid debugging.

Signed-off-by: Colin Walters <walters@verbum.org>

core: Print which xattrs are not sorted

I hit this in the rpm-ostree rechunker flow somehow
and with this change I now get:

`error: Generating commit from rootfs: Processing dir var: Writing content object: Incorrectly sorted xattr name (prev=user.Librepo.checksum.mtime, cur=security.selinux), index=2`

which is more useful, although I still need to figure out
and fix why that's happening (again?).

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3382 from alyssais/private

libostree: add private dependencies to pkg-config

Merge pull request #3383 from alyssais/libmount

libostree: remove unused libmount include

libostree: remove unused libmount include

As far as I can tell, this hasn't been used since
9a526bba ("sysroot: Handle ro /boot but rw /sysroot").

libostree: add private dependencies to pkg-config

This makes it possible to use pkg-config to link against libostree as
a static library.  Unlike shared libraries, static libraries don't
encode their dependencies in the library file, so we have to
communicate them via pkg-config.

Merge pull request #3381 from cgwalters/set-log-cb

sepolicy: Add ostree_sepolicy_set_null_log

sepolicy: Add ostree_sepolicy_set_null_log

Let's quiet the output of libselinux by default, all we
get is the pointless "regex version mismatch" warnings.
This is what e.g. systemd does.

This is exposed via the library; our binary opts in,
then we expect higher level tools like e.g. bootc to
do this too.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3377 from cgwalters/log-require-verity

prepare-root: Log when we're mounting with verity required

Merge pull request #3379 from nikita-dubrovskii/pvimg

zipl: remove 'sdboot' image before generating new one

Merge pull request #3378 from cgwalters/update-gir-follow

Update gir followup

zipl: remove 'sdboot' image before generating new one

rust: Update to glib 0.20

Since we're releasing a new version of our crates,
let's update to the latest.

Signed-off-by: Colin Walters <walters@verbum.org>

rust: Regenerate with correct Since

To ensure the recent kexec_load API has a feature gate.

Signed-off-by: Colin Walters <walters@verbum.org>

lib: Add missing Since annotations to two recent APIs

On general principle, but specfiically this is needed
to ensure the Rust binding generator correctly handles
feature flags for them.

Merge pull request #3376 from Mstrodl/feature/mstrodl/update-gir

Update GIR

Cargo: bump MSRV, need c-string literals

Signed-off-by: Colin Walters <walters@verbum.org>

rust-bindings/tests: Display no longer implemented, but Debug is

Signed-off-by: Colin Walters <walters@verbum.org>

rust-bindings: Regenerate Bindings

Signed-off-by: Colin Walters <walters@verbum.org>

rust-bindings: upgrade gir and dependencies

Signed-off-by: Colin Walters <walters@verbum.org>

prepare-root: Log when we're mounting with verity required

On general principle, but specifically as I wanted to cross-check
this when debugging something else.

Merge pull request #3375 from fossdd/musl

libotutil: Remove redundant import of prctl.h

libotutil: Remove redundant import of prctl.h

sys/prctl.h already provides prctl.h and adding both imports fails on
musl libc:

/usr/include/sys/prctl.h:88:8: error: redefinition of 'struct prctl_mm_map'
   88 | struct prctl_mm_map {
      |        ^~~~~~~~~~~~
In file included from src/libotutil/ot-unix-utils.c:33:
/usr/include/linux/prctl.h:134:8: note: originally defined here
  134 | struct prctl_mm_map {
      |        ^~~~~~~~~~~~

Merge pull request #3370 from igoropaniuk/contribute_updates

docs: update Dockerfile

Merge pull request #3371 from jmarrero/release-2025.1

Release 2025.1

configure: post-release version bump

Release 2025.1

docs: update Dockerfile

Fix issues in Dockerfile:
1. Update Fedora image to the latest version 41, otherwise docker build
   fails with an error:

   Step 1/7 : FROM registry.fedoraproject.org/fedora:28
   manifest for registry.fedoraproject.org/fedora:28 not found: manifest unknown: manifest unknown

2. Force install python3-yaml package, as it's required for running some
   tests. For example, tests/test-remote-headers.sh will fail without
   it:

   V=$($CMD_PREFIX ostree --version | \
       python3 -c 'import sys, yaml; print(yaml.safe_load(sys.stdin)["libostree"]["Version"])')
   Traceback (most recent call last):
   File "<string>", line 1, in <module>
    import sys, yaml; print(yaml.safe_load(sys.stdin)["libostree"]["Version"])
    ^^^^^^^^^^^^^^^^
   ModuleNotFoundError: No module named 'yaml'

With these fixes `make check` executes successfully in a container:
============================================================================
Testsuite summary for libostree 2024.11
============================================================================
 TOTAL: 935
 PASS:  888
 SKIP:  47
 XFAIL: 0
 FAIL:  0
 XPASS: 0
 ERROR: 0

Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>

Merge pull request #3366 from cgwalters/unconditional-cfs

Always generate composefs blob, don't enable runtime by default

Followup to https://github.com/ostreedev/ostree/pull/3353/commits/9a0acd7249bb0c7f55c2bf56e5073902cd60038b

Basically our composefs enablement flag has long had a tension between
trying to do two things:

- Enable generating the composefs blob (at deployment time)
- Enable at runtime in prepare-root

And we've hit issues in "ratcheting" enabling composefs
across upgrades because of this.

This change builds on the previous one, and now it's really
simple to talk about:

- If composefs is enabled at build time, we *always*
  generate a composefs blob at deplyment time
- Configuring the prepare-root config now mostly
  only affects the runtime state.

There is one detail though: in order to handle the
verity requirement at deploy time, we do still parse
the config then.

But for the basic "is composefs enabled at all at runtime"
that is now fully keyed off the config, not the build time
or (worse) whether the deployment happened to have a composefs
blob.

For users who want composefs on, they need to do so in the base
image configuration.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3367 from cgwalters/clang-format

tree-wide: Rerun clang-format, update ci

We have drift again here because we're using an old clang-format
in CI, and some things have landed that it didn't catch.

And update clang-format to ubuntu-24.04 so we are running
against something more modern.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3364 from ruihe774/geteuid

chore: Use geteuid() instead of getuid() to check privilege

Merge pull request #3362 from Mstrodl/feature/mstrodl/kexec2

bin/admin-upgrade: add kexec support

bin/admin-upgrade: add kexec support

Adds a new `--kexec` flag to `ostree admin upgrade` which will cause
the deployment to be loaded into kexec after the upgrade completes.
It is particularly useful in conjunction with the `--reboot` flag to
perform a reboot into the new deployment without waiting for the
(often slow) firmware initialization to take place. (And in my case,
allows me to avoid a normal reboot, which can be unreliable on my
hardware).

After an image has been loaded (using the `kexec_file_load` syscall),
the `systemctl-reboot` command (which is called when the existing
`-r` flag is included) will trigger a kexec on the loaded image
rather than a normal reboot. From `systemctl(1)`:

  If a new kernel has been loaded via kexec --load, a kexec will be
  performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1"
  has been set. If a new root file system has been set up on
  "/run/nextroot/", a soft-reboot will be performed instead of a
  reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set.

A good in-depth technical explanation of kexec can be found here:
https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html

My implementation uses the `kexec_file_load` syscall rather than the
older `kexec_load` syscall, which allows the kernel to verify the
signatures of the new kernel. It is supported on Linux 3.17 and
newer. I assume this probably won't be an issue, but if it is, it's
not that hard to put a preprocessor directive around the kexec stuff
to disable it for older kernels. Even RHEL is new enough now to
not be an issue :)

Closes: #435

chore: Check CAP_SYS_ADMIN in ot_util_process_privileged

chore: Use geteuid() instead of getuid() to check privilege

Merge pull request #3361 from cgwalters/release

Release 2024.10

Merge pull request #3351 from cgwalters/fix-transient-root-doc

man: Note semantics combining `root.transient` with `composefs.enabled`

Post-release version bump

Signed-off-by: Colin Walters <walters@verbum.org>

Release 2024.10

Signed-off-by: Colin Walters <walters@verbum.org>

man: Note semantics combining `root.transient` with `composefs.enabled`

It's all quite confusing having to reason about both the pre-composefs
ostree and the composefs version. But hopefully soon we more firmly
leave behind that first legacy.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3353 from jlebon/pr/composefs-maybe

libostree/deploy: enable composefs by default

Merge pull request #3354 from ruihe774/cfs-verity

prepare-root: Add composefs.enabled=verity

Merge pull request #3348 from qiuzhiqian/main

rofiles-fuse: when fuse execution fails, rofiles-fuse still returns exit code 0

Merge pull request #3357 from ruihe774/validate-len

sign-ed25519: Fix error message of validate_length

lib/deploy: error out if composefs enabled but unsupported

If composefs was explicitly requested (`enabled = true`) but libostree
was not compiled with composefs support, error out at deploy time. This
matches the logic in `ostree-prepare-root`.

libostree/deploy: enable composefs by default

The composefs libostree integration has been supported for a while now
and is actively in use in various ostree/bootc-based systems. Let's
turn it on by default.

This has no effect if composefs support is not compiled in. Note also
that this does not change the default value of the `composefs.enabled`
tristate to `true`. The default is still `maybe`, but the deploy API
will now also create composefs images for `maybe`.

The reason for doing it this way is so that systems upgrading from
old libostree versions (which may either not have composefs support or
may have composefs-related bugs) will still be able to upgrade and not
trip `ostree-prepare-root` in the new deployment (which allows missing
composefs images for `maybe`).

We may in the future change the default value to `true`.

See also: https://github.com/ostreedev/ostree/issues/2867

Merge pull request #3356 from cgwalters/fix-ci

Fix ci

sign-ed25519: Fix error message of validate_length

sysroot-deploy: Require fsverity when composefs.enabled=verity

prepare-root: Add composefs.enabled=verity

deny: Add Unicode-3.0

This is under e.g.
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
and is now used by the unicode-ident crate.

Switch to quay.io vs registry.ci

The old one was a mirror that seems to have finally
been decommissioned.

Merge pull request #3346 from cgwalters/commit-label-ordering

core: Always sort incoming xattrs

rofiles-fuse: Fixed the problem that when fuse execution fails, the command returns a status code of 0

testcase:
`$ sudo rofiles-fuse a b`
fuse: bad mount point `b': No such file or directory
`$ echo $?`
0

core: Always sort incoming xattrs

When recomputing selinux attrs during commit, we weren't sorting,
which could cause various issues like fsck failures.

This is a big hammer; change things so we always canonicalize
(i.e. sort) the incoming xattrs when creating a file header
and directory metadata.

I think almost all places in the code were already keeping
things sorted, but it's better to ensure correctness first.
If we ever have some performance issue (I'm doubtful) we
could add something like `_ostree_file_header_known_canonicalized`
or so.

Closes: https://github.com/ostreedev/ostree/issues/3343
Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3340 from smcv/issue3339

composefs: Ensure buffer is suitably aligned for struct fsverity_digest

composefs: Ensure buffer is suitably aligned for struct fsverity_digest

struct fsverity_digest starts with a __u16, so it will normally require
16-bit alignment, which is not guaranteed for a char array.

Resolves: https://github.com/ostreedev/ostree/issues/3339
Signed-off-by: Simon McVittie <smcv@debian.org>

Merge pull request #3337 from dabukalam/patch-1

README: Update buildstream URL to new github repo

README: Update buildstream URL to new github repo

Merge pull request #3328 from cgwalters/release

Release 2024.9

configure: post-release version bump

Signed-off-by: Colin Walters <walters@verbum.org>

Release 2024.9

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3334 from cgwalters/fix-composefs-default-docs

prepare-root: Fix composefs docs

Merge pull request #3331 from cgwalters/verity-no-verity

checkout: Only verify digest if repo requires fsverity

bootupd-static: Drop this test

It breaks due to https://bugzilla.redhat.com/show_bug.cgi?id=2308594

prepare-root: Fix composefs docs

In practice in ostree-sysroot-deploy.c we only react to having
`composefs = yes`; the docs mention `maybe` but that never did
anything.

The value is wrong in the code too, but I'm not touching
that here to avoid conflating changes - the main thing to fix
is the docs because here `maybe == no`.

Signed-off-by: Colin Walters <walters@verbum.org>

checkout: Only verify digest if repo requires fsverity

Fixes a regression from the previous commit; in
the case where the target repo doesn't have composefs in
signed mode there's no reason to verify the digest
at checkout time because we aren't verifying it at
boot time either.

The regression is in cases that use rpm-ostree e.g.
where as of recently we unconditionally add the composefs
digest, but for e.g. FCOS we aren't deploying with fsverity
enabled.

Closes: https://github.com/ostreedev/ostree/issues/3330
Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3333 from smcv/gpg-2-2-45

tests: Work around GPG 2.2.45 error behaviour when revoking an expired key

tests: Work around GPG 2.2.45 error behaviour when revoking an expired key

In GPG 2.2.45, a diagnostic message about the only trusted key having
already expired causes this import to produce exit status 2, but the
import still succeeds (the key is still revoked).

Bug: https://dev.gnupg.org/T7351
Bug-Debian: https://bugs.debian.org/1086140

Merge pull request #3332 from cgwalters/fixups-for-fcos-composefs-default

tests: Skip checking for immutable bit on composefs

tests: Skip checking for immutable bit on composefs

Needed changing after FCOS switch.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3326 from cgwalters/hack-deploy-no-verity

deploy: Don't recompute verity checksums if not enabled

deploy: Don't recompute verity checksums if not enabled

This fixes a truly horrific performance bug when
composefs is enabled, but fsverity is not supported
by the filesystem. We'd fall back to doing *userspace*
checksumming of all files at deployment time which was absolutely
not expected or required.

There's really an immense amount of technical debt
here, such as the confusion between `ex-integity.composefs`
vs the prepare-root config, how we handle "torn" states
where some objects don't have verity enabled but some do,
etc.

The ostree composefs state has two modes:

- signed: We need to enforce fsverity
- unsigned: Best effort resilience

So we fix this by making the deploy path to make verity
"opportunistic" - if the ioctl gives us the data, then we
add it to the composefs.

However, this code path is also invoked when we're
computing the expected composefs digest to inject
as commit metadata, and *that* API must work regardless
of whether the target repo has fsverity enabled as
it may operate on a build server.

One lucky thing in all of this: When I went to add
the "checkout composefs" API I added a stub `GVariant`
for options extensibility, which we now use.

Signed-off-by: Colin Walters <walters@verbum.org>